In the design and manufacture of VLSI chips, it is conventional practice that the VLSI fabrication process has a set of physical design rules for placement, wiring, and geometrical layout of the chip. There is a requirement that every chip built in the VLSI fabrication process be checked to verify conformance with the design rules. Thus, design rules checking is provided to verify that geometric shapes of circuits are not placed so closely together within the chip that they will not work. Design rules include many other rules for proper chip design including circuit-to-circuit driving rules, orthogonal conflicts, tester limitations, and other parameters.
In the IEEE Spectrum of June 1996, pp 61-7, an article called "Computer-aided Verification" by E. M. Clark and R. P. Kurshan, the major importance of design verification before going to silicon is touted. A real example of problems that can occur with poor verification is the bug found in the floating point division circuitry of Intel Corporation's Pentium chip, which brought notoriety to the high cost that is incurred when a bug is committed to silicon. The article reports that some say the cost of the bug was $500 million. Clark and Kurshan report that behind every bug that makes the news, an uncounted number of chip errors go undetected throughout the design, implementation, and marketing phases of many products. These errors will finally be detected and require corrective measures in hardware, software, or subsequent releases. Such difficulties have spurred research into methods that attempt to prove a system correct before it is built in real hardware.
The debugging or most chips and many highly complex software systems is accomplished by an elaborate testing process involving extensive runs of computer models of the target implementation. However, finding and correcting errors before going to silicon can reduce correction costs by an order of magnitude. The problem is the tremendous magnitude of the number of tests required to verify the complex chips of the state-of-the-art architecture. With chips of this complexity, billions of tests are required. For this reason, researchers have sought design verification methods that are more limited in scope. One popular design verification approach subdivides the verification problem into entities that are more easily handled by creating separate design verification tools for checking logical functions of the design, timing of the design, design rules, etc. Thus, the design rule checking verification tool relating to the present invention is one individual aspect of the overall verification problem that is accomplished separately from the other computer-aided verification tests.
The present invention relates to design rule checking, which is one part of the larger computer-aided design verification field. Design rule checking (DRC) is the process of ensuring that Very Large Scale Integration (VLSI) masks for creating circuits and wiring on a chip are created according to the proper layout criteria. The layout criteria is usually described in detail in a manual relating to a specific fabrication process. DRC is an important part of any chip design, especially with today's aggressive performance targets. DRC must accurately reflect the VLSI fabrication process in order to avoid yield losses and nonfunctional parts.
Specific design rule checks verify the shape and shape size of various circuit components which are diffused, deposited, or etched onto a chip. Design rules checking also verifies the shapes are of the proper size, shape, and type, and are within the specified proximity to adjacent shapes. A usual name for the design rules checking software program is a general purpose shapes processing program (GPSPP). The GPSPP processes inputs from two files: runset and physical layout file. The runset is a command language input file that instructs the processor executing the GPSPP how to perform the design rule checks. The runset contains several hundred individual checks. In the prior art, the runset is typically assembled and tested manually. Creating runsets by hand can introduce two significant types of errors:
1. Missed errors--the runset does not flag an error condition that it should have flagged. PA1 2. False errors--the runset flags non-existent error conditions.
The present invention automates a method for detecting whether a particular runset is missing errors or indicating false errors. The invention also facilitates the modification of an initial runset into a final runset which is corrected to eliminate both of the above errors. In addition, the method provides for verifying intentional pass and intentional fail shape configurations. Using this automated method, verifying DRC runset correctness is reduced from days to under an hour.
It is an object of the present invention to provide an automated method for establishing the correctness of a runset file which customizes a general purpose shapes processing program, such that when the runset is used for a design rules checking run all design rules violations will be detected.
It is a further object of the present invention to provide an automated method for establishing the correctness of each runset, such that the possibility is eliminated that the runset will falsely flag non-existent error conditions.
It is a further object of the present invention to provide a software methodology for verifying and debugging runsets to replace the prior art method of manually compiling the runsets.
It is a further object of the present invention to provide a system for classifying test cases using relationships that include intentional pass, intentional fail, unintentional pass, and unintentional fail configurations.